> If I have a process accepting AX.25 connections with the expectation
> that imbedded protocols (tcp/ip, net/rom, etc) will be passed up to the
> next protocol layer, but I don't have a text stream listener waiting on
> the socket, what should I do when streamtext comes along? Reply with a
> 'service not available' or 'no handler attached' message, and/or
> disconnect?
The Linux one deals with the problem by assuming you _have_ got something
set up on the AX.25 stream connection and since its policy not implementation
its up to the user process not the kernel to decide. At the moment you
always get the PMS, but a program to recv() and send a 'Facility not available'
is trivial.
Alan
------------------------------
Date: Wed, 20 Jul 94 09:27:59 +0200
From: Robert HASSON <hasson@eurecom.fr>
Subject: problems with KA9Q
To: tcp-group@ucsd.edu
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 4
I wrote to mike Chace who had advised me to contact your group for my little installing problems. So you can read my message in the attached file.
Thanks in advance
Robert Hasson
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: mail.txt
X-Sun-Content-Lines: 11
Since I have some problems with installing KA9Q on my PC I think I should let you know what they are.
Firstly I try to compile the modules with BCC and it answers me many errors relative to the <errno.h> which wasn't included in many files it was needed.
But the biggest problem I have to deal with is the mismatching between <stdio.h> and "stdio.h". Indeed, Karn had redefined the in/out modules but tries to use his own modules and the standard ones as there is an #include <stdio.h> in the file mbuf.h which is included in the stdio.c which normally includes the "stdio.h" file. So more clearly the stdio.c includes both <stdio.h> and "stdio.h".
On top of that, the dofiles function is defined in the commands.h file, used in the stdio.c and the commands.h file is never included in the stdio.c nor in the stdio.h.
You can know understand the kind of problems I have in trying to install this KA9Q. If you can see any solution to these problems please answer me.
Sincerly yours,
------------------------------
Date: Tue, 19 Jul 1994 10:09:24 -0700
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: unexpected text connections
To: brian@nothing.UCSD.EDU (Brian Kantor)
>If I have a process accepting AX.25 connections with the expectation
>that imbedded protocols (tcp/ip, net/rom, etc) will be passed up to the
>next protocol layer, but I don't have a text stream listener waiting on
>the socket, what should I do when streamtext comes along? Reply with a
>'service not available' or 'no handler attached' message, and/or
>disconnect?
What's wrong with simply dropping the connection? The data needs to
be routed on the basis of the AX.25 packet's PID (I don't like this
either, but...), so if it's not for something you are looking for,
simply drop the connection. If it is in UI mode, simply dropping
the packet should be legitimate.
>Where this happens is when a naive vanilla AX.25 user connects to a
>port that's not normally configured to handle vanilla streamtext
>connections. Just tossing the packet on the ground is uncool; it
>leaves the user wondering whether his equipment has died or what.
The question has to be what is worse, dropping the packet and leaving
the user wondering, or filling the channel with rejection packets?
Unnecessarily filling the channel may be even more uncool...
Remember, closing the connection is one packet. Sending a rejection,
then closing the connection is three (rejection notice, receive an ack,
then DM the connection).
>Or should an unattached streamtext socket become an echo server?
>That is, the naive user would just get back everything he sends?
Heavens, no. That is at least as bad as beaconing. Maybe when we
